Over the last decade, businesses and governments have been giving increasing attention to the description, automation, and management of business processes using IT technologies. The business process is the basic unit of business value within an organization.
The Business Process Execution Language for Web Services (BPEL4WS, abbr. BPEL) is an example of business process programming language for web service composition. Other languages include: BPMN, WfXML, XPDL, XLANG, WSFL, etc. These languages all describe a business process by composing web services. Generally speaking, a business process is defined in terms of its interactions with partner processes (PP). A partner process may provide services to the process, require services from the process, or participate in a two-way interaction with the process.
Mission-critical business solutions need comprehensive testing to ensure that they perform correctly and reliably. A common strategy is to subject the solution to several phases of testing such as unit, integration and system testing. Unit testing verifies the functions of a single module (class, component, process, etc). Integration testing verifies the joint functions of several modules. System testing tests the whole solution as a black-box by navigating the user interfaces (if any exist). System testing is common because it is almost the last defense for detecting fatal bugs before product release and is mandatory in traditional software development. Often the later a bug is discovered, the more expensive it is to fix. On the other hand, unit testing could be automated to make regression testing practical and efficient, which ensures newly-added functions will not affect old parts and helps control quality risks. Therefore, software engineering practice has been recently laying more emphasis on unit testing. JUnit is the most famous embodiment of this trend. Based on JUnit and its principle, many unit testing frameworks and tools have been proposed and implemented for Java, EJB, Servlet, Net, and other types of programming techniques. Unit testing tools are becoming an indispensable part of an Integrated Development Environment (IDE) and are welcomed by developers as means to improve productivity and quality.
Business process unit testing treats an individual process as the unit under test, and tests its internal logic thoroughly by isolating it from the partner processes. The reason why partner processes are simulated rather than using real partner processes lies in the following facts: 1) during the unit testing phase, some of the dependent partner processes are still under development and are thus unavailable. 2) some partner processes are developed, possibly in a totally different development environment, and are governed by other enterprises, such that the developer cannot obtain the partner processes' source code as well as related software modules to set up the running environment for the testing. 3) even with the partner processes ready for use, simulated ones are still preferred because they could generate more interaction scenarios with less effort, because answers to the process under test are faked instead of calculated according to real business logic—calling other business processes, accessing databases or interacting with humans.
In current industrial practice, business process testing focuses on system testing, e.g., the Rational Functional Tester of IBM, while unit testing has not gained any attention. The lack of a business process unit testing method and tool has resulted in the following drawbacks: 1) Processes are seldom tested in isolation, because they are inter-dependent—so it is difficult to run one process while its partner processes are not ready. 2) In the rare case of testing a process in isolation by simulating its partner processes, the partner processes are written in an ad-hoc, subjective and incomplete manner; such that services must be re-bound and redeployed and the server must be restarted for different test purposes/test cases (which are time-consuming tasks); and distributing test logic into multiple processes doesn't favor easy test maintenance and usage. 3) Test execution is performed manually without any tooling support, which does not facilitate automatic regression testing.
Current unit testing frameworks are designed for Object-Oriented (OO) programming languages, and cannot be used directly in testing business processes, which are procedure-oriented with no class concept. In addition, concurrency and synchronization are basic test requirements of business processes but haven't been supported in current frameworks. The current frameworks need to be adapted and extended to make business process unit testing possible.
Although the above-mentioned business processes programming languages are web service choreography languages, web service testing, e.g., methods and tools such as WebService Tester of Optimyz and SOAPtest of Parasoft, are not applicable to business process unit testing in general. Web service testing treats the unit under test as a black-box, only its interface definition needs to be used, with no concern with its internal implementation. In web service testing, a test case simulates the client, sends a request message and checks the response message. In business process testing, however, such a simple message exchange between the test case and the unit under test is not sufficient. Business process unit testing treats the unit under test as a white-box and the internal implementation logic needs to be used. A business process generally has many partners, with which it interacts many times according to the business logic. To test such a process, all these partners must be simulated and a complete test logic must be applied that could specify generic, complex interaction between processes. Therefore, a business process unit test case will be more complex, usually consisting of many simulated partner processes of the process under test.